Distributed data processing

ABSTRACT

A computer system includes a front end interface configured for data communications over a network with data producer terminals, multiple distributed data processors coupled to the front end interface by a data messaging infrastructure, the multiple distributed data processors including a first distributed data processor and a second distributed data processor, and an information bus coupled to the multiple distributed data processors and to multiple independent consumer modules. The first processor receives and processes data order messages for the first security, and maintains a first order book that stores outstanding orders for the first security. The second processor receives and processes received data order messages for the second security, and maintains a second order book that stores outstanding orders for the second security.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.16/556,468 filed Aug. 30, 2019, which is a continuation of U.S. patentapplication Ser. No. 15/072,874 filed Mar. 17, 2016, which is acontinuation of U.S. patent application Ser. No. 10/206,150 filed Jul.25, 2002 (now U.S. Pat. No. 9,311,673), which claims the priority ofU.S. Provisional Patent Application No. 60/385,979, entitled“Supermontage Architecture,” and filed on Jun. 5, 2002, and U.S.Provisional Patent Application No. 60/385,988, entitled “SecurityProcessor,” and filed on Jun. 5, 2002, the entire contents of each ofwhich are incorporated herein by reference in this application.

TECHNICAL FIELD

This invention relates to security transaction matching.

BACKGROUND

In a stock market, a transaction between a buyer and seller of asecurity is executed when the purchase price matches the selling price.In one example, such as the Nasdaq Stock Market, the orders are receivedfrom different market participants (such as Market Makers and ElectronicCommerce Networks) by central servers. New incoming orders are comparedagainst contra side orders in an in memory order book, and if a match isfound (i.e., a buy order matches a sell order, or vice versa), atransaction is executed. If no match is found, the new order is storedin the in memory order book to await matching with later orders.

SUMMARY

In general, in one aspect, the invention is directed towards asecurities processor that includes non-volatile storage and afirst-in-first-out queue maintained in the non-volatile storage.

The queue stores a set of events that signals a matching process thatmatches orders or quotes to complete a transaction involving a security.

Implementations of the invention may include one or more of thefollowing features. The set of events include an order to buy asecurity, an order to sell a security, an instruction to cancel aprevious order, and an instruction to modify a previous order. The setof events include a quote to sell a security, a quote to buy a security,and an instruction to modify a previous quote. The set of events includea supervisory command that affects orders or quotes related to one ormore securities. The security is listed on a public stock market. Thesecurities processor includes a random access memory for storing anorder book having one or more quotes or outstanding orders related tothe security. The securities processor includes an order entry modulethat receives orders from buyers and sellers of the security, examinesthe validity of the orders, and sends valid orders as events to thequeue. The securities processor includes a quote entry module thatreceives quotes from buyers and sellers of the security, examines thevalidity of the quotes, and sends valid quotes as events to the queue.

In general, in another aspect, the invention is directed towards asecurities processor that includes non-volatile storage, afirst-in-first-out queue maintained in the non-volatile storage to storeevents, a random access memory, and an order book maintained in therandom access memory to store one or more events corresponding to quotesor outstanding orders related to a security. The securities processincludes a matching process to receive the events from the queue,determine whether the event can be matched with a contra-side eventstored in the order book, and execute a transaction between the receivedevent and a matched contra side event if a match is found.

In general, in another aspect, the invention is directed towards amethod for processing securities transactions that includes providing aqueue in a non-volatile storage, storing events in the queue, the eventsincluding transactions related to buying or selling a security,providing an order book that stores orders and/or quotes to buy and/orsell the security, retrieving an event that is stored in the queue, anddetermining whether the event can be matched with a contra-side eventrelated to the security to execute a transaction between the receivedevent and a matched contra side event for the security if a match isfound.

Implementations of the invention may include one or more of thefollowing features. Determining whether the event can be matched with acontra-side event includes if the event relates to selling a security,determining whether the event can be matched with a pending eventrelated to buying the security. The transactions include an order to buya security, an order to sell a security, and an order to modify anearlier order. The transactions include a quote to sell a security, aquote to buy a security, and a quote to update an earlier quote. Theorder book is stored in a random access memory. Providing an order bookincludes providing an order book maintained in a random access memory.The security is listed on a public stock market. The method includesreceiving an order to buy or sell a security or to modify a previousorder, verifying the validity of the order, and storing the order as anevent in the queue. The method includes receiving a quote to buy or sella security or to modify a previous quote, verifying the validity of thequote, and storing the quote as an event in the queue. The methodincludes an event that indicates opening of a market for the transactionof the security, and an event that indicates closing of the market. Theevents include supervisory commands that affect orders or quotes relatedto one or more securities. The supervisory commands include a command tohalt transactions related to one or more securities.

The details of one or more embodiments of the invention are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram of a system for executing securitiestransactions.

FIG. 2 is a block diagram of a securities processing network.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Referring to FIG. 1, a securities processor 100 includes a matchingqueue 102 that receives events from different modules and forwards theevents to a matching process 104 that matches orders (or quotes) to buya security with orders (or quotes) to sell the security. The eventsreceived by matching queue 102 include, for example, orders, quotes,supervisory commands, delivery notifications, and delivery timeoutsignals. Matching queue 102 is maintained in a non-volatile memory (suchas a magnetic disk drive) and implemented as a first-in-first-out (FIFO)queue. By using the matching queue 102 to store events that “trigger”the matching process 104 to perform actions, the events can be processedfaster while ensuring that no events are lost due to power loss,processing error, or communication failure.

Matching queue 102 receives orders from an order entry module 106, whichin turn receives the orders from market participants 114. Order entrymodule 106 examines the orders, and passes valid orders to matchingqueue 102. Matching queue 102 receives quotes from a quote entry module108, which receives the quotes from market participants 114 as well.Quote entry module 108 examines the quotes, and passes valid quotes tothe matching queue 102. Market participants 114 are registered users ofthe security processor 100, and include, for example, market makers,electronic commerce networks (ECN), and order entry firms (e.g.,broker/dealers). Individual investors buy and sell securities throughthe market participants.

A market participant may submit multiple orders to buy (or sell) aparticular security at the same or different prices. The orders may becanceled or replaced with a new order. Each order carries a time stamp,and the orders are processed in sequence. A market participant may alsodecide not to submit any orders during a trading day. For market makers,although they do not have to submit orders, in some embodiments theymust provide a quote purchase price and a quote sell price for eachsecurity that they make a market in. By submitting the quotes prices, amarket maker warrants that it is willing to purchase the security at thepurchase quote price, and is willing to sell the security at the quotesell price. The quote prices may be updated throughout the trading day.

Securities processor 100 and supervisory module 110 reside on a server128 that is connected to a network 124 (e.g., the Internet, an intranet,or a local area network). Server 128 includes at least one centralprocessing unit (not shown) and main memory system (not shown).Typically, server 128 is a multi-processing, fault-tolerant system thatincludes multiple central processing units that each have a dedicatedmain memory system or share a common main memory pool. Software forimplementing securities processor 100 and the supervisory module 110 arestored in a storage device 130 connected to server 128. Additionally,securities processor 100 stores all information relating to securitiestransactions on storage device 130. Storage device 130 can be, forexample, a hard disk drive, a tape drive, an optical drive, a RAIDarray, a random access memory (RAM), or a read-only memory (ROM).

While being executed by the central processing unit(s) of server 16, thesoftware for implementing securities processor 100 and the supervisorymodule 110 is loaded from storage device 130 and run in main memory ofserver 128. As will be described in more detail below, during runtime,some modules of securities processor 100 will reside in main memory(which is typically random access memory), and some modules ofsecurities processor 100 will reside in storage device 130 (which istypically non-volatile storage). This allows securities processor 100 toprocess data faster by storing data in random access memory and to havefault-tolerant capability by duplicating data in non-volatile storage.

Matching queue 102 receives supervisory commands from a supervisorymodule 110 that oversees the operation of the securities processor 100.Supervisory commands may indicate, for example, market opening or marketclosing. Supervisory commands may indicate that the equipment of acertain market participant is down (“Office Outage” command), or thatthe equipment is back up running again (“Release Office Outage”command). Supervisory commands may be issued to block a marketparticipant's positions from being opened during the market openingprocess (“Prevent Open” command), or to cancel a previously enteredPrevent Open transaction (“Remove Prevent Open” command). Supervisorycommands may be issued to update a position record for a marketparticipant (“Update Position Information” command), or to purge one ormore market participants' orders (“Mass Purge” command). Supervisorycommands may indicate halt trading of a particular security, or halttrading of all securities. Matching queue 102 receives deliverynotifications from a delivery notification module 112. Deliverynotifications may indicate that a certain market participant accepted,partially accepted, or declined execution of a transaction. For example,an ECN may have issued an order to purchase 1000 shares of stock A at$10. The matching process 104 matches that order with another order tosell 2000 shares of stock A at $10. The matching process 104 delivers amessage to the ECN asking whether the ECN wishes to accept theexecution, to partially accept the execution, or to cancel the order.The ECN may accept the execution and purchase 1000 shares of stock A at$10. The ECN may partially accept the execution and purchase only 500shares of stock A at price $10. The ECN may also decide that the 1000shares of stock A at $10 has already been purchased from another stockexchange, and thus decline execution of the whole transaction conductedby matching process 104. If the ECN does not response within a presettime period, such as 30 seconds, a delivery time out module 122 sends adelivery time out event to matching queue 102 indicating that noresponse has been received from the ECN. Market participants 114 mayissue orders or quotes faster than matching process 104 is capable ofhandling, such as when unexpected heavy trading of certain securitiesoccur. By using the matching queue 102 as intermediary between matchingprocess 104 and modules 106, 108, 110, and 112, there is no need for ahand-shaking procedure to ensure safe delivery of the events. There isno need for the matching process to send an acknowledgement to themodule sending the event to indicate correct receipt of the event. Byusing the matching queue 102, a module sending an event only has tocorrectly write the event into the matching queue 102, and does not needto know when the event will be processed by the matching process 104. Aslong as the event is safely stored in the matching queue 102, the eventwill eventually be processed by the matching process 104. By notrequiring matching process 104 to send acknowledgement signals, matchingprocess 104 can process events faster. Modules 106, 108, 110, 112, and114 can also operate more efficiently without having to wait for theacknowledgement from the matching process 104.

Because the message queue is implemented in non-volatile memory, theevents are not lost when the security processor 100 loses power. Whenpower is restored, matching process 104 can compare the message queue102 with an order file 116 that serves as a log file to record theevents that have been received by the matching process 104. The matchingprocess 104 then processes the events that have not been processed inthe sequence stored in the matching queue 102.

When the matching process 104 receives a new order (or quote) to buy orsell a security, matching process 104 compares that order (or quote)with the orders (or quotes) already stored in an in memory order book118 that is resident in main memory 126. In memory order book 118 ismaintained in main memory 126 or alternatively, a level of cache memoryor equivalent that is typically implemented as random access memory. Ifthe new order (or quote) can be matched with a “contra-side” order (orquote) stored in the in memory order book 118, the matching process 104executes the transaction. The contra-side order of a buy order is a sellorder or a sell (or sometimes referred to as an ask) quote, and thecontra-side order of sell order is a buy order or a buy (or sometimesreferred to as a bid) quote. The matching process removes the alreadymatched order from the in memory order book 118, and writes a record ofthe transaction to a report queue 120. The report queue 120 is used tobroadcast the transaction to other modules (not shown in the figure) inthe securities processor 100. If the new order (or quote) cannot bematched with another order (or quote) in the in memory order book 118,the new order is stored in the in memory order book 118 to awaitmatching with later orders (or quotes).

When the matching process 104 receives an event indicating an update ofa quote purchase or sell price of a security for a market maker,matching process 104 updates the quote purchase or sell price andcompares the updated quote with quotes from other market makers andorders already stored in the in memory order book 118. If the updatedquote can be matched with other quotes or orders, the matching process104 executes the transaction (and removes the already matched order fromthe in memory order book 118 if appropriate), and writes a record of thetransaction to the report queue 120.

When the matching process 104 writes to the in memory order book 118,matching process 104 simultaneously writes to an order file 116 storedin a non-volatile storage device (such as a magnetic disk drive). Othermodules (not shown in the figure) can determine the content of in memoryorder book 118 by accessing order file 116, but only the matchingprocess 104 can access the in memory order book 118. This ensures thatmatching process 104 can process events reliably at a high speed whilekeeping downstream modules up-to-date on the latest transaction details.Because order file 106 is stored in a non-volatile storage device, datais not lost when the power is lost, so the matching process 104 canreconstruct the in memory order book 118 from the order file 116 after apower failure.

The following describes the important events that may be sent to thematching queue 102.

“New Order” event: This event is sent by the order entry module 106 toplace a new order on a security.

“Cancel/Replace” event: This event is sent by the order entry module 106to cancel an old order and place a new order on the in memory order book118 with a new time stamp. The orders are processed by the securitiesprocessor 100.

“Quote Update” event: This event is sent by the quote entry module 106to update a quote position of a market participant.

“Order Reinstate” event: This event is sent by the quote entry module106 to reinstate an order that was canceled.

“Delivery Message” event: This event contains a delivery message, and issent by the delivery notification module 112.

“Security Halt” event: This event is sent by the supervisory module 110in unusual cases (e.g., when there is material news that may affect thestock price) to suspend trading in a security and place the security ina “trade halt” status. When the matching process 104 reads this event,process 104 cancels all quotes related to that security and put ordersrelated to that security in “not available” status. When the security isin the “trade halt” status, quote updates are not allowed, and orderswith “not available” status cannot be matched with other orders.

“Security Halt Release” event: This event is sent by the supervisorymodule 110 to allow quotes of the security to be entered. When thematching process 104 receives this event, process 104 changes orders inthe “not available” status to “open” status to resume trading of thesecurity.

“Pre Open” event: This event is sent by the supervisory module 110 priorto market open (e.g., around 9:29:30 AM) to signal the matching process104 to review all orders in each security and execute orders that arelocking or crossing.

“Market Open” event: This event is sent by the supervisory module 110prior to market open (e.g., around 9:30:00 AM) to signal the matchingprocess 104 to mark each security as having an “open” status to allowtrading of the security.

“Market Close” event: This event is sent by the supervisory module 110at a predetermined time (e.g., around 4:00 PM) to signal the matchingprocess 104 to close the quote positions that have close time at thepredetermined time. For the quote positions that remain open after thepredetermined time, the matching process 104 calculates the quotepositions to be displayed to the public.

“Emergency Market Condition Halt” event: This event is sent by thesupervisory module 110 in unusual circumstances (e.g., when certainmarket index drops steeply and reach a lower threshold) to signal thematching process 104 to stop execution of all orders.

“Emergency Market Condition Release” event: This event is sent by thesupervisory module 110 to signal the matching process 104 to resumeexecution of each order.

“Apply Dividends” event: This event is sent by the supervisory module110 to signal the matching process 104 to adjust the prices, sizes, andreserve sizes of relevant orders depending on the type of dividend. Forexample, if the dividend is a stock split 2 for 1, all prices inrelevant buy orders are reduced by half and the sizes are doubled. For acash dividend, the cash amount of the dividend is subtracted from thebuy order price. Sell orders are not adjusted.

“Rollback of Dividends” event: This event is sent by the supervisorymodule 110 to signal the matching process 104 to roll back the dividendchanges previously applied. This may occur when the supervisory module110 previously entered dividends by mistake.

“Office Outage” event: This event is sent by the supervisory module 110to signal that a market participant has equipment problems and is unableto conduct business. When the matching process 104 receives this event,process 104 adjusts the quotes and orders of this market participant toan “outage” status. These orders are temporarily unavailable and notdisplayed to the public.

“Office Release” event: This event is sent by the supervisory module 110to signal that a market participant is ready to participate in themarket again. When the matching process 104 receives this event, process104 checks whether by changing the “outage” status will cause the marketparticipant's old orders and quotes to lock or cross the market. If themarket will be locked or crossed, the “outage” status is not changed.The market participant is required to enter new quotes or orders that donot create locked or crossed market conditions. The matching process 104then adjusts the quotes and orders from the “outage” status to “open”status so that the quotes and orders are reachable (i.e., can be matchedwith contra side quotes or orders).

“Mass Order Purge” event: This event is sent by the supervisory module110 to purge all the orders and/or quotes for a specified security ormarket participant. When matching process 104 receives this event, itreviews the in memory order book 118 and purges all orders and/or quotesthat corresponds to the specified security or market participant.

“Registration” event: The event is sent by the supervisory module 110.Before a market participant can enter quotes and conduct transactions ina security, the market participant needs to register for that security.When the matching process 104 receives the “registration” event, process104 creates a position for the market participant in a specifiedsecurity. After registration, quotes and orders from the marketparticipant relating to the registered security will be accepted.

FIG. 2 shows a securities processing network 200 using securitiesprocessors 100. Securities processing network 200 includes a front endmodule 202 for receiving orders (or quotes) from market participants114, order collection modules 206 that process the orders (or quotes),the supervisory module 110, and downstream modules 210 for processinginformation related to transactions that have been executed. The frontend module 202 produces a graphical user interface to allow marketparticipants 114 to easily access the services of the securitiesprocessing network 200.

A messaging infrastructure 204 allows messages to be communicated amongthe front end module 102 and the order collection modules 206. Adownstream information bus 208 provides a “message publish/subscribe”mechanism in which the order collection modules 206 publish messagesonto bus 208, and the downstream modules 210 subscribe to messages onthe bus 208.

Securities processing network 200 allows scalability so that more ordercollection modules 206 may be added to network 200 as the transactionvolume increases. Each order collection module 206 is assigned toprocess orders (or quotes) related to predetermined types of securities.Each order collection module 206 can serve one or more securitiesprocessors, each securities processor handling a subset of securitiesfor which the order collection module 206 is responsible. The mapping ofsecurities to the order collection modules (or securities processors) isstored in a table that can be updated. The update process may occurafter market close. Each day, the transaction volumes of the ordercollection modules 26 are analyzed, and the mapping table is updated tobalance the transaction volume of each order collection module 206 andsecurities processor 100.

Different methods may be used to distribute the work-load among variousorder collection modules 206 and securities processors 100. For example,one order collection module 206 may process securities with symbolsstarting from A-C, while another order collection module 206 may processsecurities with symbols starting from D-F, etc. A securities processormay be dedicated to process a single security with a large transactionvolume.

Downstream modules 210 include, for example, broadcast modules 212,vendor feed modules 214, and information modules 216. Broadcast modules212 receive information from the securities processors 100 through thedownstream information bus 208 and broadcast the information tosubscribers of the information. Vendor feed modules 214 allow vendors(e.g., market participants) to send queries (e.g., inquire about thelast ten transactions for a certain security) to the securitiesprocessors and receive information in responses to those queries.Information modules 216 receive information from the bus 208, processthe information according to predefined formats, and send the formattedinformation to subscribers (e.g., news wire agencies).

The “publish/subscribe” architecture of the downstream information bus208 allows for horizontally scalable processing in the downstreamapplications. The publish/subscribe architecture inserts a layer ofindependence between data producers (publishers) and data consumers(subscribers). If a new application needs, for example, last tradeinformation, such information can be inserted into the bus 208, and thesubscriber (the new application) can subscribe to the last tradeinformation with no effect on the publisher (or publishers) of the lasttrade information. This architecture isolates data consumers from dataproducers.

Order collection modules 206 (including securities processors 100) andsupervisory module 100 described above may find applicability in anycomputing or processing environment and with any type of machine that iscapable of running a computer program. The order collection modules andthe supervisory module may be implemented in hardware, software, or acombination of hardware and software. For example, the order collectionmodules and the supervisory module may be implemented in a circuit thatincludes one or a combination of a processor, a memory, programmablelogic and logic gates. The order collection modules and the supervisorymodule may also be implemented in computer programs executed onprogrammable computers/machines that each includes a processor, astorage medium or other article of manufacture that is readable by theprocessor (including volatile and non-volatile memory and/or storageelements), at least one input device, and one or more output devices.Program code may be applied to data entered using the input device togenerate output information.

The programs may be implemented in a high level procedural orobject-oriented programming language to communicate with thecomputers/machines. The programs may also be implemented in assembly ormachine language. The language may be a compiled or an interpretedlanguage. Each computer program may be stored on a storage medium ordevice (e.g., CD-ROM, hard disk, or magnetic diskette) that is readableby a general or special purpose programmable computer for configuringand operating the computer when the storage medium or device is read bythe computer to perform the processes. The order collection modules andthe supervisory module may also be implemented as a machine-readablestorage medium, configured with a computer program, where uponexecution, instructions in the computer program cause the computer tooperate and perform the functions of the order collection modules andthe supervisory module.

Although some implementations have been described above, otherembodiments are also within the scope of the following claims. Forexample, the matching queue 102 may receive events or commands otherthan the ones described. The matching queue 102 may receive events frommodules other than the ones described.

1. A computer-implemented method comprising: receiving, at a first oneof multiple distributed data processors, data order messages from a datamessaging infrastructure including an order for a first security;processing, at the first distributed data processor, data order messagesspecific to the first security; storing, in a first order book in randomaccess memory associated with the first distributed data processor,outstanding orders for the first security; receiving, at a second one ofmultiple distributed data processors, data order messages from datamessaging infrastructure including an order for a second securitydifferent from the first security; processing, at the second distributeddata processor, data order messages specific to the second security; andstoring, in a second order book in random access memory associated withthe second distributed data processor, outstanding orders for the secondsecurity.